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(54) Verfahren, Vorrichtungen und Software-Programme zur Nachrichtenubermittlung zwischen 
Telekommunikations-Netzwerkelementen 



(57) Es wird ein Verfahren zur Nachrichtenubermitt- 
lung zwischen Telekommunikations-Netzwerkelemen- 
ten, die bei MMS (Multimedia Service)-Diensten betei- 
ligt sind, vorgestellt, welches sich dadurch auszeichnet, 
daf3 Nachrichten von einem MMS-Relay iiber eine 
Schnittstelle (Ge*) mittels eines CAP (CAMEL Applica- 



tion Part) Protokolls an einen SCP/CSE (Service Con- 
trol Point/CAMEL Service Environment) und/oder um- 
gekehrt versendet werden. Weiterhin betrifft die Erfin- 
dung entsprechende Vorrichtungen sowie Software- 
Programme. Mittels der Erfindung kann insbesondere 
ein einfaches Online Charging bei Nutzung von 
MMS-Diensten realisiert werden. 
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Beschreibung 

[0001] Die Erfindung betrifft ein Verfahren zur Nach- 
richtenubermittlung zwischen Telekommunikati- 
ons-Netzwerkelementen, die bei MMS (Multimedia 
Messaging Service)-Diensten beteiligt sind. 
[0002] Des weiteren betrifft die Erfindung entspre- 
chende Vorrichtungen sowie Software- Programme. 
[0003] In der Mobilfunktechnologieistes vorgesehen, 
mittels sog. Multimedia Messaging Service (MMS) 
Dienste neue Moglichkeiten der Zurverfugungstellung 
und Ubertragung von Daten zu erschlieBen. MMS-lnhal- 
te bestehen aus einem oder mehreren Elementen, wie 
Text, Sprache, Bildern und Video. Genaueres hierzu fin- 
det sich in den Publikationen von 3GPP (3 rd Generation 
Partnership Project) und ETSI (European Telecommu- 
nications Standards Institute), deren Inhalte - wie auch 
die der anderen im folgenden genannten Dokumente - 
hiermit explizit in die Offenbarung einbezogen werden. 
Hinsichtlich der Realisierung von Multimedia Messa- 
ging Service Diensten wird beispielsweise auf 3GPP TS 
22.140 V4.0.1 und 3GPP TS 23.140 V4.1 .0 verwiesen. 
[0004] In den genannten Spezifikationen wird ein On- 
line-Charging fur MMS gefordert, d.h. Realisierung von 
Abrechnungsmoglichkeiten fur die Inanspruchnahme 
der MMS-Dienste. Hierfur werden Gebuhrendatensatze 
(Charging Data Records) in verschiedenen beteiligten 
Netzwerkelementen erzeugt, insbesondere dem 
MMS-Relay, dermit einem MMS-Server verbunden ist. 
Der MMS-Server ist verantwortlich fur die Zwischen- 
speicherung und die Handhabung von Nachrichten, 
wahrend das MMS-Relay zwischen dem MMS-Server 
und dem jeweiligen Nutzer (User Agent) vermittelt und 
somit u.a. die Integration verschiedener Servertypen in 
verschiedenen Netzwerken ermoglicht. Wie ein solches 
Online-Charging realisiert werden konnte, ist jedoch in 
den genannten Spezifikationen nicht beschrieben. 
Ebenso ist es bisher nicht moglich, auf einfache Weise 
die Versendung von MMs (Multimedia Messages) an- 
hand des noch vorhandenen Budgets des Nutzers zu 
kontrollieren. Allgemein ist die einfache Zurverfugung- 
stellung von Subscriber-lnformationen noch weitge- 
hend ungelost. 

[0005] Es ist Aufgabedervorliegenden Erfindung, die 
vorgenannten Probleme im Stand derTechnikzu besei- 
tigen und insbesondere eine Gebiihrenerfassung bzw. 
ein Online-Charging fur MMS in einfacher Weise zu er- 
moglichen. 

[0006] Diese Aufgabe wird bei dem Verfahren derein- 
gangs genannten Art dadurch gelost, daf3 Nachrichten 
von einem MMS-Relay uber eine Schnittstelle mittels ei- 
nes CAP (CAMEL Application Part) Protokolls an einen 
SCP/CSE (Service Control Point/CAMEL Service Envi- 
ronment) und/oder umgekehrt versendet werden. 
[0007] Weiterhin wird diese Aufgabe bei einem 
MMS-Relay gelost durch Mittel zum Verarbeiten, Emp- 
fangen und/oder Senden von Nachrichten von einem 
oder an einen SCP/CSE. Bei einem SCP/CSE wird die- 



se Aufgabe gelost durch Mittel zum Verarbeiten, Emp- 
fangen und/oder Senden von Nachrichten von einem 
oder an einen MMS-Relay. 

[0008] Weiterhin wird diese Aufgabe hinsichtlich der 

5 Software- Pro gram me durch die Merkmale der unab- 
hangigen Anspruche 22 und 23 gelost. 
[0009] Die Erfindung, die sich insbesondere fur 
GPRS- und UMTS-Dienste einsetzen laBt, beruht dar- 
auf, das dem jeweiligen Teilnehmer zugeordnete 

10 MMS-Relay uber ein CAP Protokoll (CAMEL Applicati- 
on Part) an den SCP (Service Control Point)/CSE (CA- 
MEL Service Environment) anzubinden. SCPs sind Da- 
tenbanken, die Informationen hinsichtlich fortgeschritte- 
ner Anruf-verarbeitender Moglichkeiten zur Verfiigung 

15 stellen und die Diensteerbringung zu einem Subscriber 
(Kunden, Teilnehmer) kontrollieren. CAMEL (Customi- 
sed Applications for Mobile Network Enhanced Logic) 
ist ein netzwerkbasierendes Werkzeug, das dem Netz- 
werkbetreiber hilft, dem Kunden (Subscriber) betreiber- 

20 spezifische Dienste anzubieten. Dies ist insbesondere 
auch dann moglich, wenn sich diese Subscriber auBer- 
halb des HPLMN (Home Public Land Mobile Network) 
befinden (Roaming). So ermoglicht CAMEL z.B. den 
weltweiten Zugriff zu betreiberspezifischen Intelligent 

25 Network-Anwendungen wie bspw. Prepaid und Super- 
vision. Wenn ein Kunde (Subscriber) die CAMEL-Unter- 
stutung benotigt, werden insbesondere die Prozeduren 
aufgerufen, die dem VPLMN (Visited PLMN) und dem 
HPLMN die notwendigen Informationen mitteilen. 

30 [0010] Urn CAMEL einzufuhren, ist der CAP (CAMEL 
Application Part), bestehend aus einem CSE (Camel 
Service Environment) und einem CCS7 (Common Con- 
trol Signaling System 7, SS7), erforderlich. SS7 ist eine 
Architekturzum Informationsaustausch zwischen Tele- 

35 phonnetzen, insbesondere zur Ausfuhrung von out-of- 
band signaling zur Unterstutzung z.B. der Anrufdurch- 
fuhrung, der Rechnungsstellung und dem Routing. 
[0011] Der wesentliche Gedanke der Erfindung ist 
nun derjenige, eine Kommunikation zwischen MMS-Re- 

40 lay und SCP/CSE mittels eines CAMEL-Protokollstacks 
zu realisieren. ZweckmaBigerweise wird hierzu auf dem 
MMS-Relay ein an das MMS-Relay angepaRtes SSF 
(Serving Switching Function) implementiert, welches 
die Kommunikation mit dem SCP/CSE ubernimmt. Im 

45 folgenden ist dieser SSF mit mmsSSF bezeichnet, urn 
die Zuordnung zum CAMEL-Service zu verdeutlichen. 
Mittels dieser Ausgestaltung ist es insbesondere mog- 
lich, daf3 das MMS-Relay Daten und/oder Befehle aus 
dem betreffenden SCP/CSE abfragt, urn dann die MM 

50 und/oder damit zusammenhangende Daten entspre- 
chend zu behandeln, zu verarbeiten oder solche Aktio- 
nen zu vermitteln, z.B. zum Zwecke der Vergebuhrung. 
Beispiele hierzu werden weiter unten gegeben. Gegen- 
uber dem Stand der Technik, d.h. der Anbindung des 

55 SCP/CSE an ein SGSN (Serving GPRS Support Node) 
oder ein HLR (Home Location Register) ergibt sich so- 
mit der Vorteil einerdirekten Kommunikation hinsichtlich 
nutzerspezifischer Daten durch das MMS-Relay vom 
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SCP/CSE. 

[0012] Nachdem das M MS- Relay den Kontakt zum 
SCP/CSE aufgenommen hat, ubernimmt bevorzugt der 
SCP/CSE die logische Steuerung. Vorzugsweise ent- 
scheidet also der SCP/CSE uber die Behandlung der 
MMs und sendet Instruktionen zum M MS -Relay uber 
die Behandlung der MMs. Der mmsSSF wird in diesem 
Fall zum "ausfuhrenden Organ". 

[0013] Das vorgestellte Prinzip ist eine konsequente 
Weiterfuhrung der bereits vorhandenen Online Char- 
ging Verfahren fur leitungsvermittelte (Circuit Switched) 
oder paketvermittelte (Packet Switched) Datenubertra- 
gung und SMS. Es laBt sich leicht in bereits vorhandene 
PLMN Netzstrukturen integrieren. Die notwendigen 
Protokoll-Erweiterungen auf SCP Seite sowie die Ein- 
fuhrung eines mmsSSF sind ohne groBeren Aufwand 
durchzufuhren. 

[0014] Ein wesentlicher Vorteil, den mmsSSF im 
MMS-Relayzu implementieren, istdie Moglichkeit eines 
"Content-Chargings". Hierzu wird dem SCP der 
MMS-Typ (z.B. MP3, MPEG4 : WAV, JPEG, ...) mitge- 
teilt. Abhangig von dem ubermittelten MMS-Typ kann 
der SCP die MM vergebuhren. Weiterhin wird durch die 
Anbindung an den SCP/CSE via CAMEL-Protokoll ein 
Roaming zu anderen Netzbetreibern ermoglicht. 
[0015] Bei einer bevorzugten Ausfiihrungsform der 
Erfindungsetztdaszwischen dem MMS-Relay und dem 
SCP/CSE zu verwendende CAP Protokoll auf das oben 
genannte Signaling System No. 7 (SS7) auf. Es kann 
somit die ohnehin schon vorhandene Architektur des 
SS7 genutzt werden. 

[001 6] Alternativ setzt das zu verwendende CAP Pro- 
tokoll auf einem IP-Protokollstack auf, welcher fur die 
HLR-Anbindung mittels eines MAP (Mobile Application 
Part) Protokolls notwendig ist. MAP / CAP (Phase 4) 
over IP ist noch in der Standardisierungsphase, wird 
aber vermutlich fur das Release 4 (die Bezeichnung 
"Release 2000" wird nicht mehrverwendet, Rel. 4 istmit 
Rel. 2000jedoch identisch) verabschiedet werden. Da 
die PDN (Public Data Network) Struktur auf IP basiert 
und die Standardisierung fur die Zukunft des PLMNs 
(Public Land Mobile Network) ebenfalls die umfassende 
Verwendung von IP propagiert, ist ein IPbasierender 
Protokollstack eine besonders bevorzugte Ausfuh- 
rungsform der Erfindung. Dieses Vorgehen hat zudem 
den Vorteil. daf3 es nicht erforderlich ist, einen zusatzli- 
chen Protokollstack im MMS-Relay zu realisieren. 
[0017] Damit eine sinnvolle Abfrage des SCP/CSE 
durch das MMS-Relay erfolgen kann, ist es zweckma- 
Big, daB das MMS-Relay weiB, welche CAMEL-Dienste 
fur den Teilnehmer zur Verfugung stehen. Vorteilhafter- 
weise sind diese Informationen in dem HLR des Teilneh- 
mers abgelegt und werden vom MMS-Relay des Teil- 
nehmers abgefragt. Bei der Abfrage des HLR seitens 
des MMS-Relays wird dann eine MMS-CSI (CAMEL 
Subscription Information) ubermittelt, welche Subscri- 
ber-lnformationen enthalt. Eine MMS-CSI wird vorzugs- 
weise fur versendete (O-MMS-CSI) und empfangene 



(T-MMS-CSI) MMs vergeben. Anhand dieser MMS-CSI 
kann das MMS-Relay erkennen, welche(r) CAMEL 
MMS-Dienst(e) fur den Teilnehmer nutzbar sind. Ein sol- 
cher Dienst kann z.B. die Prepaid-Nutzung sein. An- 
5 hand dieser Informationen kann dann das MMS-Relay 
den CSP/CSE nach Einzelheiten hinsichtlich dieses 
Dienstes fragen. Im Falle des genannten Prepaid-Dien- 
stes konnte dies z.B. das noch vorhandene Budget des 
Teilnehmers sein. 
10 [0018] Die Erfindung ist insbesondere einsetzbar zur 
Ausfuhrung der jeweiligen Verfahrensschritte bei Netz- 
werkknoten bzw. -elementen vom Typ MMS-Relay und 
SCP/CSE. Die Implementierung erfolgt durch entspre- 
chende, von der Erfindung mitumfaBte Software-Pro- 
's gramme, die auf die genannten Vorrichtungen entspre- 
chend ladbar und/oder auf diesen ablaufbar sind. 
[0019] Vorteilhafte Weiterbildungen sind durch die 
Merkmale der Unteranspruche gekennzeichnet. 
[0020] Im folgenden werden einige Ausfuhrungsbei- 
20 spiele anhand derZeichnung nahererlautert. Es zeigen: 

Fig. 1 eine Telekommunikations-Netzwerk-Architek- 
turmit Anbindung eines MMS-Relays an einen 
SCP/CSE via CAP-Protokoll; 

25 

Fig. 2 einen moglichen Befehlssatz zwischen einem 
MMS-Relay und einem SCP/CSE; 

Fig. 3 einen Befehlsaustausch zwischen einem 
30 MMS-Relay und einem SCP/CSE bei erfolg- 

reicher Vergebuhrung, und 

Fig. 4 einen Befehlsaustausch zwischen einem 
MMS-Relay und einem SCP/CSE bei zu gerin- 
35 gem Budget. 

[0021] Die Fig. 1 zeigtdie Netzwerkarchitektur paket- 
vermittelter Datendienste und die Anbindung eines 
MMS-Relays, wie sie in vielen Punkten Stand derTech- 

40 nik ist. Die Erfindung ist jedoch nicht auf paketvermittel- 
te Datendienste beschrankt, sondern kann beispiels- 
weise auch bei leitungsvermittelten Datendiensten ein- 
gesetzt werden. Insbesondere ist die Erfindung fur 
GPRS und UMTS einsetzbar. Die in der Fig. 1 darge- 

45 stellte Netzstruktur entspricht im wesentlichen der Ar- 
chitektur, wie sie beispielsweise aus der Fig. 2 der 3G 
TS23.060 bekannt ist. Zur Erlauterung der vorliegenden 
Erfindung ist lediglich ein Ausschnitt aus dieser Archi- 
tektur von Bedeutung. Fur weitere Details wird auf die 

50 obige Quelle sowie die Spezifikationen ETSI GSM 
12.15 V6.2.0 und ETSI TS 32015 V3. 4.0 verwiesen. 
[0022] Ein Endgerat enthalt in einem als Mobile Ter- 
mination MT bezeichneten Teil alle zur Funkubertra- 
gung notwendigen Funktionen und weiterhin die Teil- 

55 nehmerschnittstelle am Terminal TE, uber die Ende-zu- 
Ende-Verbindungen zwischen Anwendungen realisiert 
werden. R bezeichnet einen Bezugspunkt zwischen ei- 
nem nicht-ISDN kompatiblen TE und einem MT. Uber 



30 



3 



5 



EP 1 278 383 A2 



6 



einen Bezugspunkt Uu ist das MT mit einem Zugangs- 
netz zur Ermoglichung des Zugangs zum UMTS-Netz 
verbunden. Das Zugangsnetzwerk, auch AND (Access 
Network Domain) genannt, kann gemaR Fig. 1 entweder 
durch ein UTRAN (UMTS Terrestrial Radio Access Net- 
work) Oder durch ein GSM-BSS (Global System for Mo- 
bile Communication - Base Station (Sub)System) reali- 
siert werden. Ein MT kann iiber das UTRAN mittels ei- 
nersog. lu-Schnittstelle oder iiber das BSS mittels einer 
Schnittstelle Gb mit der Core Network Domain verbun- 
den werden. 

[0023] Die Core Network Domain ist im wesentlichen 
mittels zweier Netzwerkknoten implementiert. Dies ist 
einerseits das SGSN (Serving GPRS Support Node) 
und andererseits das GGSN (Gateway GPRS Support 
Node). Das SGSN kann somit GPRS sowohl fur GSM 
als auch UMTS unterstiitzen. Das SGSN und das 
GGSN sind iiber eine Schnittstelle Gn miteinander ver- 
bunden. Wie im unteren Teil der Fig. 1 angedeutet, kann 
das SGSN mit weiteren SGSNs oder GGSNs anderer 
Netze kommunizieren ("anderes PLMN", Public Land 
Mobile Network). 

Das GGSN kann iiber eine Schnittstelle Gi mit einem 
MMS-Relay Verbindung aufnehmen, welches iiber eine 
Schnittstelle MM2 mit einem MMS-Server (Multimedia 
Messaging Service - Server) verbunden ist. Das 
MMS-Relay und der MMS-Serversind Bestandteil eines 
PDN (Public Data Network). 

[0024] In einem sog. Home Location Register (HLR) 
sind iiblicherweise Packet Domain (PD) Daten entspre- 
chend den individuellen Daten von einzelnen Teilneh- 
mern und Routing-lnformationen enthalten. Hierbei ist 
das HLR u.a. iiber eine sog. Gr-Schnittstelle vom 
SGSN, iiber eine sog. Gc-Schnittstelle vom GGSN und 
iiber eine sog. MM5-Schnittstelle von einem MMS-Re- 
lay zuganglich. 

[0025] Es ist vorgesehen, daf3 die HLR-Funktionalitat 
heutiger PLMN-Netze von einem HSS (Home Subscri- 
ber Server) ubernommen bzw. erganzt wird. Die ent- 
sprechenden Protokolle und Schnittstellen sind dann 
hieran anzupassen. Zwar wird die Erfindung im folgen- 
den anhand des Einsatzes eines HLR erlautert; grund- 
legende Unterschiede gegeniiber dem Einsatz eines 
HSS bestehen aber nicht. 

[0026] Gebiihrendatensatzen (Charging Records), 
die Informationen iiber die in Anspruch genommenen 
Dienstleistungen enthalten (s. bspw. ETSI GSM 12.15 
V6.2.0 und ETSI TS 132015 V3.4.0) werden von den 
SGSN und GGSN erstellt und zu einem Abrechnungs- 
system, dem sog. Billing System (BS), des Netzbetrei- 
bers iibertragen. Gebuhreninformationen werden vor- 
zugsweise fiirjede Mobilstation durch die SGSNs und 
GGSNs, die diese Mobilstation bedienen ; gesammelt. 
Der SGSN sammelt fur jede MS Gebiihreninformatio- 
nen, die mit der Nutzung des Funknetzwerks zusam- 
menhangen, wahrend der GGSN fur jede Mobilstation 
Gebuhreninformationen sammelt, die mit der Nutzung 
des externen Datennetzwerks zusammenhangen. Die 



Schnittstelle zwischen GPRS und dem externen Paket- 
datennetzwerk wird mit Gi bezeichnet. Zudem sammeln 
beide Knoten, SGSN und GGSN, teilnehmerbezogene 
Gebuhreninformationen betreffend die Nutzung der 

5 GPRS Netzwerkresourcen. Auch in den Elementen des 
Multimedia Messaging Services (MMS) ist es vorgese- 
hen, daB CDRs erzeugt werden. Die Moglichkeit, CDRs 
in einem MMS-Relay zu erzeugen, ist in 3G 
TS22.140V4.0.1 (§8) und in 3G TS23.1 40V4.1 .0 (§5.3) 

10 beschrieben. 

[0027] In einem SCP (Switching Control Point) mit ei- 
nem CSE (CAMEL Service Environment) sind benutzer- 
spezifische Daten abgelegt, z.B. Informationen iiber die 
Hone des Guthabens eines Teilnehmers eines Prepaid- 

15 Dienstes. Zur Dateniibertragung zu anderen Netzwer- 
kelementen wird eine sog. CAMEL (Customised Appli- 
cations for Mobile Network Enhanced Logic) Architektur 
bzw. ein CAP Protokoll (CAMEL Application Part) ver- 
wendet. 

20 [0028] Der InformationsfluG zwischen SGSN und 
SCP/CSE wird bevorzugt folgendermaBen initialisiert: 
Das SGSN erhaltvom HLR Informationen iiber das Vor- 
handensein eines speziellen Dienstes. Beispielsweise 
wird vom HLR eine Bestatigung oder eine Verneinung 

25 hinsichtlich der Nutzungsberechtigung des Teilnehmers 
an das SGSN ubermittelt und dort uberpriift, ob der Be- 
nutzeruberhauptdie Berechtigung hat, abgehendeMul- 
timedia-Nachrichten zu verschicken (sog. Subscription 
Check). Gleichfalls kann im HLR abgelegt sein, ob der 

30 Teilnehmer ein Prepaid-Nutzer ist. Diese Informationen 
werden iiber eine Schnittstelle Gr an das SGSN weiter- 
geleitet. Dieses kann dann iiber eine Schnittstelle Ge 
vom SCP/CSE z.B. das Guthaben des Teilnehmers er- 
fahren und entsprechend die Weiterleitung einer MM an 

35 das GGSN veranlassen oder verhindern. 

[0029] ErfindungsgemaB ist nun zur Kommunikation 
zwischen dem MMS-Relay und dem CSP/CSE eben- 
falls eine Dateniibertragung moglich. Hierzu wird eine 
neue Schnittstelle benotigt, die hier mit Ge* bezeichnet 

40 sei. Die Kommunikation iiber diese Schnittstelle ge- 
schieht ebenfalls mittels eines CAP Protokolls. 
GemaG der Erfindung wird ein bereits im MMS-Relay 
fur die HLR-Anbindung gefordertes SS7 oder alternativ 
ein IP Protokollstack verwendet und ein darauf aufset- 

45 zendes CAMEL Protokoll fur MMS-spezifische Nach- 
richten (Operationen) erweitert. Zur Behandlung dieser 
Nachrichten wird zweckmaGigerweise in dem MMS-Re- 
lay ein mmsSSF eingefuhrt. Ein bereits bestehender 
gsmSCF im SCP/CSE muB um die entsprechenden 

50 Nachrichten erweitert werden. Damit der MMS-Relay 
erkennen kann, ob es sich bei dem Teilnehmer bspw. 
um einen Prepaid Teilnehmer handelt, fragt das 
MMS-Relay Subscriber-lnformationen vom HLR ab. 
Diese Subscriber-lnformationen miissen um eine soge- 

55 nannte MMS-CSI (CAMEL Subscriber Information) er- 
weitert werden. Der Unterschied zum Stand derTechnik 
besteht darin, daf3 nicht nur das SGSN Informationen 
vom SCP/CSE erhalten kann, sondern auch das 
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MMS-Relay. Hierdurch wird es dem MMS-Relay ermog- 
licht, dem SCP/CSE insbesondere gebuhrenrelevante 
Daten zu ubermitteln, die dieser verarbeitet und ggf. ei- 
ne Nachricht an das MMS-Relay zuriicksendet. Gleich- 
falls kann ein sog. Content Charging im SCP/CSE rea- 
lisiert werden. Hierbei erhalt das SCP/CSE vom 
MMS-Relay Informationen uber den ubermittelten 
MMS-Typ und die GroBe der MMS (z.B. MP3-Datei mit 
einer GroBe von 3 MByte). Art und GroBe bestimmen in 
diesem Fall die Hone der dem Teilnehmer berechneten 
und von seinem Konto abzuziehenden Gebuhren. Des 
weiteren istwegen der Verwendungdes CAP-Protokolls 
ebenfalls ein Roaming moglich. 
[0030] Vorteilhafterweise werden gemaB der Fig. 2 ei- 
ne oder mehrere derfolgenden Nachrichten zum Zwek- 
ke des MMS Online Charging in den CAMEL Standard 
(3GPP TS 23.078, 3GPP TS 29.078) eingefugt. Die Na- 
men sind hierbei zweckmaBig gewahlt und keineswegs 
zwingend. 

• lnitial_DP_MMS (vom MMS-Relay zum SCP/CSE) 
Die Nachricht wird in dem MMS-Relay erzeugt und 
an den gsmSCF gesendet, wenn von dem 
mmsSSF, welcher in dem MMS-Relay liegt, eine 
MM von einem Prepaid Teilnehmer erkannt wurde. 
In dieser Nachricht werden dem SCP/CSE gebuh- 
renrelevante Informationen mitgeteilt, wie z.B. 
MMS-Volumen (kByte), ein Zeitstempel und der 
MMS-Type (s. 23.240v41 0 §5.1 .2). Durch die Uber- 
mittlung des MMS-Typs wird es dem SCP/CSE er- 
moglicht, ein Content Charging durchzufuhren. Der 
MMS-Relay wartet nun auf weitere Anweisungen 
vom SCP/CSE. 

• Request_Report_MMS_Event(vom SCP/CSE zum 
MMS-Relay) 

Mit dieser Nachricht kann der SCP/CSE den Bericht 
uber weitere Ereignisse anfordern. Hierzu kann die 
erfolgreiche Zustellung der MM zum Empfanger 
oder die erfolgreiche Speicherung der MM im 
MMS-Server gehoren. 

• Event_Report_MMS (vom MMS-Relay zum SCP/ 
CSE) 

Mit dieser Nachricht wird der SCP/CSE uber das 
Eintreten eines Ereignisses informiert. Ein mogli- 
ches Ereignis ist das erfolgreiche oder fehlerhafte 
Zustellen bzw. Speichern einer MM zum bzw. im 
UE/MMS-Server. Durch Abfrage dieser Ereignisse 
kann sichergestellt werden, daf3 dem Prepaid Teil- 
nehmer keine MM vergebuhrt werden, die z.B. auf- 
grund von Netzproblemen (PLMN, PDN) nicht zu- 
gestellt werden konnten. 

• Furnish_Charging_lnformation_MMS (vom SCP/ 
CSE zum MMS-Relay) 

Mit Hilfe dieser Nachricht konnen weitere Zusatzin- 
formationen vom SCP/CSE in den Gebuhrendaten- 



satzen (Charging Data Records, CDR) abgespei- 
chert werden. Es konnen mehrere FCIs (Furnish 
Charging Information) mit einer maximalen Lange 
von 1 60 Octets versendet werden. Diese Beschrei- 
5 bung lehnt sich an die bestehende SMS Spezifika- 
tion in der 3GPP TS 23.078 §7.6.2.3 an. 

• Continue_MMS (vom SCP/CSE zum MMS-Relay) 
Anhand der vom MMS-Relay ubermittelten Gebuh- 

10 ren-lnformationen wird die MM des Prepaid Teil- 
nehmers vergebuhrt, sein vorhandenes Budget al- 
so reduziert. Mit der Nachricht Continue_MMSw\r6 
dem MMS-Relay erlaubt, die MM zuzustellen. Die 
Nachricht Continue_MMS wird all gem ein verwen- 

15 det, urn einem SSF mitzuteilen, daB er seine Ver- 
arbeitung fortfuhren kann. Dies gilt fur die "Event-" 
und "Trigger Detection Points", die im Request Mo- 
de "armiert" worden sind : siehe (Request Modes, s. 
3GPPTS 23.078). 

20 

• Release_MMS (vom SCP/CSE zum MMS-Relay) 
Wenn der SCP/CSE anhand der iibertragenen Ge- 
buhren-lnformationen festgestellt hat, daB das auf 
dem SCP/CSE verfugbare Budget nicht mehr aus- 

25 reicht, urn die MM zuzustellen, wird dem MMS-Re- 
lay anhand der Nachricht Release_MMS mitgeteilt, 
daf3 die Nachricht nicht zugestellt werden darf. 

[0031] Anhand der Fig. 3 und 4 werden zwei entspre- 

30 chende Beispiele naher erlautert. 

[0032] Die Fig. 3 zeigt den Nachrichtenaustausch 
zwischen einem MMS-Relay und einem SCP/CSE bei 
erfolgreicher Vergebuhrung einer MM. Folgender Nach- 
richten- oder Operationsablauf wird vorteilhafterweise 

35 gemaB der Fig. 3 bei erfolgreicher Vergebuhrung durch- 
laufen: 



1 . Das MMS-Relay stellt fest, daB ein Prepaid Teil- 
nehmer eine MM versenden mochte. Das Zustellen 
40 der MM wird unterbrochen. Das MMS-Relay baut 
eine Verbindung zum SCP/CSE auf und fordert mit- 
tels der Operation lnitial_PD_MMS weitere Instruk- 
tionen vom SCP/CSE an. 

45 2. Der SCP/CSE kann nun optional mittels der Ope- 
ration Request_Report_MMS_Event die Mitteilung 
uber bestimmte Ereignisse ("Event Detection 
Points") anfordern. Hier kann z.B. eine Bestatigung 
fur das erfolgreiche Abspeichern der MM auf dem 

50 MMS-Server angefordert werden. Anstelle des Ab- 
fragemodus (Request Mode, s. 3GPP TS 23.078) 
kann auch eine Ubertragung von Ereignismitteilun- 
gen vom MMS-Relay an den SCP/CSE ohne spe- 
zielle Anforderung erfolgen. 

55 

3. Mit der Operation Continue_MMS wird dem 
mmsSSF/MMS-Server mitgeteilt, daB ausreichend 
Budget vorhanden ist, urn diese MM zu vergebiih- 



20 
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ren, und daB die MM zugestellt werden darf. 

4. Das MMS-Relay bestatigt in der Operation E- 
vent_Report_MMS z.B. das erfolgreiche Speichern 
der MM auf einem MMS-Server. 

5. Dem Prepaid Teilnehmer wird jetzt das Zustellen 
einer MM auf dem SCP/CSE vergebuhrt. 

6. Der SCP/CSE ubermittelt mittels der Operation 
FCI_MMS optional dem mmsSSF Gebuhreninfor- 
mationen, die in das CDR (Gebuhrenticket bzw. Ge- 
buhrendatensatz) des MMS-Relays zusatzlich ein- 
getragen werden sollen. 

7. Mit der Operation Continue_MMS wird dem 
mmsSSF mitgeteilt, daft er mit der Verarbeitung 
fortfahren kann (nur im Request Mode) und die 
SS7/IP Verbindung zum SCP/CSE abgebaut wer- 
den soil. 

[0033] Die Fig. 4 stellt die zwischen dem MMS-Relay 
und dem SCP/CSE ausgetauschten Nachrichten bzw. 
Operationen fur den Fall einer abgewiesenen MM auf- 
grund zu geringen Budgets dar. 

1 . Das MMS-Relay stellt fest. daB ein Prepaid Teil- 
nehmer eine MM versenden mochte. Das Zustellen 
der MM wird unterbrochen. Das MMS-Relay baut 
eine Verbindung zum SCP/CSE auf und fordert mit- 
tels der Operation In itial_PD_M 'MS weitere Instruk- 
tionen vom SCP an. 

2. Der SCP/CSE stellt fest daB das Budget des 
Prepaid Teilnehmers aufgebraucht ist. Mit der Ope- 
ration Release_MMS\N\rti dem mmsSSF mitgeteilt, 
daB er die Anforderung, diese MM zuzustellen, zu- 
riickweisen soil. 

[0034] Die Erfindung kann sowohl fur ausgehende 
(originated) als auch fur eingehende (terminated) MMs 
eingesetzt werden. Im ersten Fall kommuniziert das 
MMS-Relay des Absenders mit seinem SCP/CSE, im 
zweiten Fall das MMS-Relay des Empfangers mit dem 
entsprechenden SCP/CSE. Die beiden MMS-Relays 
von Sender und Empfanger und/oder die beiden SCP/ 
CSE konnen auch identisch sein. 
[0035] Hinsichtlich der Vorrichtungen umfaBt die Er- 
findung insbesondere die Zurverfugungstellung der not- 
wendigen Mittel zum Empfangen, Verarbeiten und/oder 
Senden derbesagten Nachrichten. Hierzu sind entspre- 
chende Prozessormittel sowie Sende- und/oder Emp- 
fangsvorrichtungen - allgemein Kommunikationsein- 
richtungen - vorzusehen. 

[0036] Unter den beschriebenen und beanspruchten 
Netzwerkkomponenten einschlieBlich der Schnittstel- 
len, Protokolle und Verbindungen untereinander sind 
auch diejenigen zukunftiger Entwicklungen zu verste- 



hen, die im wesentlichen die gleichen Aufgaben haben 
werden wie die hier beschriebenen. 



5 Patentanspriiche 

1. Verfahren zur Nachrichtenubermittlung zwischen 
Telekommunikations-Netzwerkelementen, die bei 
MMS (Multimedia Service)-Diensten beteiligt sind, 

10 dadurch gekennzeichnet, 

daB Nachrichten von einem MMS-Relay uber eine 
Schnittstelle (Ge*) mittels eines CAP (CAMEL Ap- 
plication Part) Protokolls an einen SCP/CSE (Ser- 
vice Control Point/CAMEL Service Environment) 

15 und/oder umgekehrt versendet werden. 

2. Verfahren nach Anspruch 1 , 
dadurch gekennzeichnet, 

daB die Nachrichtenubermittlung mit Hilfe eines im 
20 MMS-Relay implementierten SSF (Serving Swit- 
ching Function, mmsSSF) erfolgt. 

3. Verfahren nach einem dervorhergehenden Anspru- 
che, 

25 dadurch gekennzeichnet, 

daB die Nachrichtenubermittlung mit Hilfe eines im 
SCP/CSE implementierten SCF (Serving Control 
Function, gsmSSF) erfolgt. 

30 4. Verfahren nach einem dervorhergehenden Anspru- 
che, 

dadurch gekennzeichnet, 

daB das CAP Protokoll auf das SS7 (Signaling Sy- 
stem No. 7) aufsetzt. 

35 

5. Verfahren nach einem Anspruche 1 bis 3. 
dadurch gekennzeichnet, 

daB das CAP Protokoll auf einen IP (Internet Pro- 
tocol) -Protoko I Istack aufsetzt. 

40 

6. Verfahren nach einem dervorhergehenden Anspru- 
che, 

dadurch gekennzeichnet, 

daB das MMS-Relay vom HLR (Home Location Re- 
45 gister) Oder vom HSS (Home Subscriber Server) 
hinsichtlich der dem Teilnehmer zur Verfugung ste- 
henden CAMEL MMS-Dienste entsprechende 
MMS-CSI (Charging Subscription Information) an- 
fordert und/oder empfangt. 

50 

7. Verfahren nach Anspruch 6, 
dadurch gekennzeichnet, 

daB das MMS-Relay MMS-CSI fur versendete MMs 
(Multimedia Messages; O-MMS-CSI, Originated 
55 Multimedia Messaging Service Charging Subscrip- 
tion Information) und/oder empfangene MMs 
(T-MMS-CSL Terminated Multimedia Service Char- 
ging Subscription Information) anfordert und/oder 
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empfangt. 

8. Verfahren nach einem dervorhergehenden Ansprii- 
che, 

dadurch gekennzeichnet, 5 

daB nach Kontaktaufnahme durch das M MS- Relay 
zum SCP/CSE der SCP/CSE die logische Steue- 
rung ubernimmt und Instruktionen zum M MS- Relay 
liber die Behandlung der MM sendet. 

10 

9. Verfahren nach einem dervorhergehenden Ansprii- 
che, 

dadurch gekennzeichnet, 

daB vom MMS-Relay zum SCP/CSE eine Oder 
mehrere der folgenden Nachrichten ubermittelt is 
werden: 



10. Verfahren nach einem dervorhergehenden Ansprii- 25 
che, 

dadurch gekennzeichnet, 

daB vom SCP/CSE zum MMS-Relay eine oder 
mehrere der folgenden Nachrichten ubermittelt 
werden: 30 



11. Verfahren nach einem dervorhergehenden Anspru- 45 
che, 

dadurch gekennzeichnet, 

daB im SCP eine Vergebiihrung zu Lasten eines 
Teilnehmerkontos aufgrund der Inanspruchnahme 
eines MMS-Dienstes durch einen MM-Absender 50 
und/oder MM-Empfangers vorgenommen wird. 

12. Verfahren nach einem dervorhergehenden Ansprii- 
che, 

dadurch gekennzeichnet, 55 

daB die Vergebiihrung Art (MMS-Typ, z.B. MP3, 
MPEG4, WAVm JPEG) und/oder Umfang (Dateien- 
gr63e) der MM betrifft. 



13. MMS-Relay, 
gekennzeichnet durch 

Mittel zum Verarbeiten, Empfangen und/oder Sen- 
den von Nachrichten von einem oder an einen SCP/ 
CSE. 

14. MMS-Relay nach Anspruch 13, 
dadurch gekennzeichnet, 

daB eine oder mehrere der folgenden Nachrichten 
an den SCP/CSE versendbar sind: 

gebiihrenrelevante Informationen, z.B. 
MMS-Volumen, Zeitstempel und/oder 
MMS-Typ {lnitial_DP_MMS); 
Ereignisse betreffend die Verarbeitung einer 
MM, z.B. Zustellung und/oder Versendung 
( Request_ Report_MMS_ E ven t) . 

15. MMS-Relay nach Anspruch 13 oder 14, 
dadurch gekennzeichnet, 

daB ein mmsSSF (Service Switching Function) im- 
plementiert ist. 

1 6. MMS-Relay nach einem der Anspriiche 1 3 bis 1 5, 
gekennzeichnet durch 

Mittel zur Kommunikation mit dem SCP/CSE iiber 
ein CAP-Protokoll, das auf ein SS7 oder einen 
IP-Protokollstack aufsetzt, welches auch fur die 
HLR- oder HSS-Anbindung iiber ein MAP-Protokoll 
verwendet wird. 

17. MS-Relay nach einem der Anspriiche 13 bis 16, 
gekennzeichnet durch 

Mittel zur Anforderung, zum Empfang und/oder zur 
Verarbeitung von MMS-SCI (CAMEL Subscription 
Information) von einem HLR oder einem HSS iiber 
eine Schnittstelle (MM5). 

18. SCP/CSE, 
gekennzeichnet durch 

Mittel zum Verarbeiten, Empfangen und/oder Sen- 
den von Nachrichten von einem oder an einen 
MMS-Relay. 

19. SCP/CSE nach Anspruch 18, 
dadurch gekennzeichnet, 

daB eine oder mehrere der folgenden Nachrichten 
an das MMS-Relay versendbar sind: 

Anforderung an das MMS-Relay zur Ubersen- 
dung von bestimmten Ereignissen, z.B. ob eine 
erfolgreiche Speicherung und/oder Zusendung 
der MM erfolgt ist 

( Request_ Report_MMS_ E ven t) ; 
Zusatz information en zur Abspeicherung in Ge- 
biihrendatensatzen im MMS-Relay 
(Event_Report_MMS) ; 

Erlaubnis, eine MM zuzustellen 



gebiihrenrelevante Informationen, z.B. 
MMS-Volumen, Zeitstempel und/oder 
MMS-Typ {lnitial_DP_MMS) ; 20 
Ereignisse betreffend die Verarbeitung einer 
MM, z.B. Zustellung und/oder Versendung 
( Request_Report_ MMS_ E ven t) . 



Anforderung an das MMS-Relay zur Ubersen- 
dung von bestimmten Ereignissen, z.B. ob eine 
erfolgreiche Speicherung und/oder Zusendung 
der MM erfolgt ist 35 

( Request_Report_ MMS_ E ven t) ; 
Zusatzinformationen zur Abspeicherung in Ge- 
biihrendatensatzen im MMS-Relay 
(Event_Report_MMS) ; 

Erlaubnis, eine MM zuzustellen 40 
(Continue_MMS); 

Mitteilung, eine MM nicht zuzustellen 
{Release_MMS). 
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(Continue_MMS); 

Mitteilung, eine MM nicht zuzustellen 
(Release_MMS). 

20. SCP/CSE nach Anspruch 18 oder 19, 5 
dadurch gekennzeichnet, 

daB ein gsmSCF (Service Control Function) imple- 
mentiert ist. daB zum Zwecke der Verarbeitung, des 
Empfangs und/oder der Ubermittlung einer oder 
mehrerer der Nachrichten nach Anspruch 9 und/ 10 
oder 1 0 entsprechend erweitert ist. 

21. SCP/CSE nach einem der Anspruche 18 bis 20, 
gekennzeichnet durch 

Mittel zur Kommunikation mitdem MMS-Relay uber 15 
ein CAP-Protokoll, das auf ein SS7 oder einen 
IP-Protokollstack aufsetzt, welches auch fur die 
HLR- oder HSS Anbindung uber ein MAP-Protokoll 
verwendet wird. 

20 

22. Software-Programm, welches auf einer Vorrich- 
tung, insbesondere einer Vorrichtung nach einem 
der Anspruche 1 3 bis 21 , derart ablaufen kann, daB 
das Software-Programm mitsamt der Vorrichtung 

die Verfahrensschritte auf der Seite des MMS-Re- 25 
lays oder des SCP/CSE gemaB einem der Anspru- 
che 1 bis 12 ausfuhrt. 

23. Software-Programm, welches in eine Vorrichtung, 
insbesondere einer Vorrichtung nach einem der An- 30 
spruche 1 3 bis 21 , ladbar ist, so daB die derart pro- 
grammierte Vorrichtung fahig oder angepaBt ist, 
Verfahrensschritte auf der Seite des MMS-Relays 
oder des SCP/CSE gemaB einem der Anspruche 1 

bis 12 auszufuhren. 35 
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